设计模式|策略模式

OO设计原则

1. 封装变化
2. 针对接口编程&＃xff0c;而不是针对实现编程
3. 多用组合&＃xff0c;少用继承

《head first 设计模式》思路

初始需求&＃xff1a;设计日志SDK&＃xff0c;支持多种打印方式&＃xff1a;文件日志/标准输出打印/socket日志&＃xff08;想象有几十个子类&＃xff09;&＃xff0c;设置多种日志格式

1. 继承&＃xff0c;抽象Super Class

• 定义日志超类&＃xff08;superclass&＃xff09;&＃xff0c;因为每种appender打印方式不同&＃xff0c;print() 方法是抽象的。

需求2: 增加一个新功能&＃xff0c;设置标准输出日志颜色
2. 覆盖继承过来&＃xff0c;却不需要的方法&＃xff08;文件日志不需要&＃xff09;

• 问题&＃xff1a;setColor() 方法加入到超类不合适&＃xff0c;子类需要覆盖&＃xff0c;比较笨

3. 接口化&＃xff0c;设置颜色定义为接口&＃xff0c;子类按需implement

• 问题&＃xff1a;存量类都需要修改&＃xff0c;代码会变多

4. 设计原则1&＃xff0c;抽离容易改变的

• 容易改变&＃xff0c;例如设置日志格式

5. 设计原则2&＃xff0c;面向接口编程&＃xff0c;而不是面向对象。声明的对象不要限定类型。

• 颜色接口&＃xff0c;定义具体的实现类。后面可以无限增加实现类&＃xff0c;即不会影响存量的行为类&＃xff0c;也不会影响使用者的日志类。

原文的图片如下&＃xff0c;原文以设计duck应用为例

问题&＃xff1a;如何动态改变日志类的某个行为&＃xff0c;例如同步打印/异步阻塞打印/异步非阻塞打印

6. 增加同步/异步接口&＃xff0c;增加一些实现类&＃xff0c;然后超类中&＃xff0c;增加设置同步异步方式的方法

• 子类实例&＃xff0c;可以在运行时调用set方法&＃xff0c;来实现动态改变行为

总结

策略模式-定义算法族&＃xff0c;分别封装&＃xff0c;使得算法实现和使用算法的客户端分离